正気を疑う技術 - bugのないvibe codingを目指して
AIによって80点程度のコードを書く速度は劇的に上がりました。問題は、出てきたコードを誰がどう信じるかです。Helpfeelはインフラ・金融機関向けにもサービスを提供している為、開発者はAIを盲信せずコードを理解する必要があります。本セッションではAI対話コンテキスト抽出・批判的思考の連鎖・sanity-review等の自作ツールを使い、説明と実装の一致から、やらない事とその理由の妥当性までを確認する開発手法を紹介します。AIに実装させるだけでなく、AIに正気を疑わせる開発プロセスです。
こんにちは。橋本翔 (shokai)ですshokai.icon
Helpfeel Cosenseのプロダクトマネージャー
https://scrapbox.io/files/6959fb4e0714533920025da8.jpg
イオンの丸鶏(1200円ぐらい)に、S&Bの鳥香草焼きスパイスミックス(100円ぐらい)とオリーブオイル塗って、ヘルシオで焼くのにはまっています
鶏の丸焼き
これはAI Engineering Summit Tokyo 2026の発表資料です
右のメニューのStart presentationでスライドになります
今日の話
会社紹介（スポンサーセッションなので）
AIや人を信じるには
作ったAgent Skill × 3個
最近社内で推奨している、AIを使った開発フロー
株式会社Helpfeel
Gyazo.icon Gyazo
全世界で利用されるスクリーンショット共有ツール
Helpfeel.icon Helpfeel
自己解決AIシステム
FAQ・AIチャットボット・VoC分析が完結
顧客対応・社内サポートなど、あらゆるナレッジをAIで即活用
Cosense.icon Cosense (旧Scrapbox)
あらゆる情報を整理できる画期的な知識共有サービス
このWikiの事
私が作っていますshokai.icon
Helpfeel 導入先一覧（一部）
https://scrapbox.io/files/6a25f334601c8b4efdcf8ceb.png
各社の公開FAQは https://www.helpfeel.com/showcase で触れます
社内FAQ等は除く
求人もしています
https://recruit.helpfeel.com/
Cosense
複数人で同時編集できるWiKi
Helpfeelの編集画面でもある
最近、地銀やインフラ系の顧客が増えている
例：伊予銀行の問合せ対応画面の開発プロセス
人を、信じたい
登場人物
人間
shokai.icon PdM
開発メンバー.icon 開発者
AIが加わった
claude code.iconCodex CLI.icon
AIや人が信じられない
直接AIを使うぶんには、まあまあ信じれる
shokai.icon ↔ Claude Code.icon
別の人を挟むと、だんだん信じられなくなってくる
shokai.icon ↔ 開発メンバー.icon ↔ Claude Code.icon
AIでコード書かれて、AIでプルリクの説明も書かれると、レビューがつらい
AIや人を信じたい
開発メンバー.icon ↔ Claude Code.iconで何をやりとりしたのかshokai.iconは知りたい
Claude Code.iconが出力するコードの品質を上げたい
最終的に作られたコードをshokai.iconが正しく理解したい
開発メンバー.iconが正しく要件を理解しているか、shokai.iconは知りたい
shokai.iconがどういう観点でコードレビューしているか、開発メンバー.iconは知りたい
2025年以前はだいたいこれで足りていた
/Nota/ナレッジワーカーとしてのレビューのもらい方
https://scrapbox.io/files/6a261df0601c8b4efdcfed60.png
コードレビューは作業結果のダブルチェックではない
2025年からAIで開発するようになった
1人が出すpull requestの数はあまり増えてない
少なくともshokai.iconの見ている範囲では
かわりに1つのpull requestのサイズが大きくなった
サイズそのままで数が増えた会社もありそう？
大きいpull requestが増えた
例：MongoDBをバックエンドとしたベクトル検索機能
リリース初日から、これまで数年間ESでの全文検索で培った運用ノウハウと同等のものを全て実装できてしまう
https://scrapbox.io/files/6a2570d2601c8b4efdcf1617.png
同時編集からの同期遅延と取りこぼし救出、テナント毎のオンデマンドembedding構築、後からmodel交換など
デカいpull requestが来てもどうにかなってる
その方法を話します
今年2月ごろ作ったAgent Skill
1. codex-consultation
2. conversation-context-export, conversation-context-import
3. sanity-review
1. codex-consultation
「相談して」という軽いトリガーで、AI同士に激しい仮説・反論・再検証をやらせるスキル
https://github.com/shokai/agent-skills/blob/main/plugins/codex-consultation/skills/codex-consultation/SKILL.md
経緯
2025年冬ごろ
Claude Code.iconで実装した後、Codex CLI.iconにセカンドオピニオンさせるとbugが見つかるなあshokai.icon
そして板挟みへ
Claude Code.icon ↔ shokai.icon ↔ Codex CLI.icon
コピペが大変
事情説明も大変
特に、Claude Code.iconと話し合ったやらない事とその理由がCodex CLI.iconに伝わっていないのがつらい
「スクリーンショット向けの変更だからJPEG対応してないのはbugではないんです」
shokai.icon ↔ Claude Code.icon ↔ Codex CLI.icon という構成で普通に呼び出させてみた
Claude Code.iconがただの連絡係になる
Codex CLI.iconが◯◯と言ってました、主張が正しいかは知らんけどClaude Code.icon
結局shokai.iconは2人分の報告を受け取るだけ、大変すぎる
批判的思考の連鎖を導入
めちゃくちゃ賢くて暇な部下が2人いたらやらせてみたかったやつ
Claude Code.iconへ
問題解決しろ
自分の見解を開示しつつ、Codex CLI.iconに指示を出せ
Codex CLI.iconへ、知的好奇心を持て
指示された事はちゃんとやれ
指示されてない事もやれ
指示や前提そのものを疑って検証しろ
Claude Code.iconへ、中間管理職としての度量を持て
レポートの内容は疑え
指示してない事まで書かれたレポートを受け止め、それを一つずつ吟味して報告書を書け
網羅的で正確なbugレポートが出てくる
15分ぐらいかかるけど
ここまでshokai.iconと話して決まったやらない事とその理由に基づいて、自動的にトリアージされて便利
例：Codex CLIと相談するAgent Skillの相談の深さを調整する
Skillで言葉の意味を上書きする
これで発動する
Codexと相談して
「相談して」「確認してもらって」「調べてもらって」「協力して」などのおだやかな日本語が、このAgent Skillsによって全て乗っ取られる
Claude Code.iconとCodex CLI.iconの間では、相談とか協力はそういう物になっている
こんなカロリーの高いコミュニケーション私はやりたくないshokai.icon
賢いAI同士でやってもらう
Claude Code.icon ↔ Codex CLI.iconを必要に応じて2往復までやる
shokai.iconにレポートするまで20分ぐらいかかる
おまけ
Agent SkillでCodex CLIを呼び出してレビューに使うなら、起点はOpusではなくHaikuでいいのか？
だめです
Codexが単に賢いのか、それとも相談という行為自体に価値があるのか
ある。けどcodexのsandboxがすごい
人やAIを信じたい
開発メンバー.icon ↔ Claude Code.iconで何をやりとりしたのかshokai.iconは知りたい
Claude Code.iconが出力するコードの品質を上げたい → codex-consultation
最終的に作られたコードをshokai.iconが正しく理解したい
開発メンバー.iconが正しく要件を理解しているか、shokai.iconは知りたい
shokai.iconがどういう観点でコードレビューしているか、開発メンバー.iconは知りたい
2. conversation-context-exportとconversation-context-import
コードに残らない意思決定を引き継ぐスキル
https://github.com/shokai/agent-skills/blob/main/plugins/conversation-context/skills/conversation-context-export/SKILL.md
https://github.com/shokai/agent-skills/blob/main/plugins/conversation-context/skills/conversation-context-import/SKILL.md
経緯
AIと色々相談しながら開発していると勉強になる
一緒に試行錯誤したり
途中で技術的制約が見つかったり
突然AIで作ったコードだけ渡されてもレビューできないのは、この部分が共有できてないからなのでは？
2025年冬ごろまで
とりあえずtmuxのwindowのキャプチャを撮るで会話ログを全部取っていた
長すぎて読めなかった
チャットログを整理しよう
やった事はコード読めばわかる。AIにも解説してもらえるし
重要なのはやらない事とその理由なのではないか？
コードになってない部分
色々検討した結果、こうなりました開発メンバー.icon
「色々検討した」の部分を詳しく教えてくれshokai.icon
コードレビューではそれを見たい
章立て
ブランチ名、更新日時、commit hash
目的
設計方針
却下した代替案
意図的に対応しないこと
発見された制約
新たに確認できた事実
注意が必要な難所
残作業
https://github.com/shokai/agent-skills/blob/main/plugins/conversation-context/skills/conversation-context-export/TEMPLATE.md
https://scrapbox.io/files/6a25a4d5601c8b4efdcf552d.png
Claude Codeの/compactコマンドと相性がいい
長いセッションでも記憶が飛ばない
特に、やらない事とその理由を絶対引き継げるのが助かるshokai.icon
例：今回はPNGだけやる、JPEGは対応しない、スクリーンショット用の機能だから
引き継げないと、codex-consultationで無限にJPEG対応を指摘される
Claude Code.icon ↔ Codex CLI.iconで話しあって、shokai.iconに報告せずに解決したbugがまとまる
Codexに確認してもらい、単純なbugであれば修正してください。解決方法が複数ある場合は私に質問してくださいというプロンプトを愛用している
これで解決したbugが、対話コンテキストに残る
複数回exportしても壊れない
特に前任者が発見した事実は、再検証して覆るまで勝手に書き換えないように指示してある
人やAIを信じたい
開発メンバー.icon ↔ Claude Code.iconで何をやりとりしたのかshokai.iconは知りたい → conversation-context-export
Claude Code.iconが出力するコードの品質を上げたい → codex-consultation
最終的に作られたコードをshokai.iconが正しく理解したい
開発メンバー.iconが正しく要件を理解しているか、shokai.iconは知りたい
shokai.iconがどういう観点でコードレビューしているか、開発メンバー.iconは知りたい
3. sanity-review
作業結果だけでなくプロセスも確認するAgent Skill
コードレビューは作業結果のダブルチェックではない
https://github.com/shokai/agent-skills/tree/main/plugins/sanity-review
経緯
開発者として
最終的に作られたコード（の仕様）をshokai.iconが誤って理解している可能性がある
顧客や社内に説明する必要がある
対話コンテキストに書かれているやらない事とその理由って本当に妥当なのか？
もう一回やってみたらできるのではないか？
まだbugがありそうで心配
レビュアーとして
開発メンバー.iconが正しく要件を理解しているか、shokai.iconは知りたい
自分がどういう観点でコードレビューしているか明らかにしておきたい
チェックするもの
概要欄がまともか
何をなぜやってどうなったのか、を実装者は説明できているか
概要欄と実装の比較
説明と実装が一致しているか
実装者はAIが作ったコードを読み解けているのか
実装の質
bugや脆弱性が含まれていないか
実装者の考慮に漏れ・抜けはないか
調べた事、試した事、やらない事とその理由の記述に十分な厚みがあるか
章立て
AIとの対話コンテキスト
pull request概要欄
サマリー
品質評価
説明と実装の整合性
命名・設計パターンの一貫性
長期視点で命名・設計を考察する
バグ・脆弱性の調査
考慮漏れの確認
レビュー作業において発生した問題
結論
https://github.com/shokai/agent-skills/blob/main/plugins/sanity-review/skills/sanity-review/TEMPLATE.md
いろいろな所にcodex-consultationが使われている
出力例
説明がまともか、コードとの整合性とれてるか
https://scrapbox.io/files/6a25e87a601c8b4efdcf853c.png
bugの指摘と反論
https://scrapbox.io/files/6a25e8ec601c8b4efdcf859f.png
Codex CLI.iconの容赦ない指摘を、事情を知ってるClaude Code.iconがトリアージ手伝ってくれる
結論
https://scrapbox.io/files/6a25e91f601c8b4efdcf85ce.png
効能
説明と実装が一致していない事が指摘される
頻繁に怒られすぎて、最近は事前にpull requestの概要欄とレビューコメントを書きました。間違いや説明不足な点があれば指摘してくださいで軽くチェックするようになってしまったshokai.icon
bugがよく取れる
https://scrapbox.io/files/6a25e203601c8b4efdcf8102.png
bugが無いプルリクって存在しないんじゃないかと思ってしまうshokai.icon
概要欄を宣言的に書く
確認項目が3つある場合、3つ宣言する
sanity-reviewとcodex-consultationが疑ってくれる
例
AIに「JSをTSに書き直しました。動作が変化してしまっていないか確認してください」と指示するのではなく
pull request概要欄に「いくつかのJSをTSに書き直しました。動作は変更していません」と書く
AIに「API v2を追加したが、API v1の動作は変化してしまっていませんか？後方互換性を維持したいので確認してほしい」と指示するのではなく
pull request概要欄に「API v2を追加した。後方互換性を維持するため、API v1の動作は一切変更していない」と書く
AIに「このブランチで新規実装したserver API全てに、testの実装漏れがないか確認してください」と指示するのではなく
pull request概要欄に「新規実装した全てのserver APIは、アクセス権限を持たないユーザーを拒否する事を確認するtestが実装されている」と書く
レビューと修正を繰り返す時にも便利
pull requestにFAQを書こう
https://scrapbox.io/files/6a25eb26601c8b4efdcf8753.png
今はやらない事を書くのもアリ
そして今後こう実装する予定、まで書いて良い。ついでにチェックしてもらえる
概要欄
paginationするならupdated順やめるて_id順にするべきshokai.icon
https://scrapbox.io/files/6a25def7601c8b4efdcf7ef7.png
sanity-review
そうだねClaude Code.iconCodex CLI.icon
https://scrapbox.io/files/6a25df5e601c8b4efdcf7f32.png
人やAIを信じれるようになった
開発メンバー.icon ↔ Claude Code.iconで何をやりとりしていたのかshokai.iconは知りたい → conversation-context-export
Claude Code.iconが出力するコードの品質を上げたい、bug無くしたい → codex-consultation
最終的に作られたコードをshokai.iconが正しく理解したい → sanity-review
開発メンバー.iconが正しく要件を理解しているか、shokai.iconは知りたい → sanity-review合格後の概要欄
shokai.iconがどういう観点でコードレビューしているか、開発メンバー.iconは知りたい → sanity-review
第一部完
ありがとうございました
第二部
最近社内で推奨している、AIを使った開発フロー
書き出してみると、意外とややこしい事やってるなと思ったshokai.icon
環境
Claude Code (Opus)とCodex CLI (GPT5.5-high)を使っています
IMEの辞書によく使うプロンプトを入れておく
https://scrapbox.io/files/6a25b26b601c8b4efdcf609f.png
実装する
0. AIと技術相談する
難しい新機能追加や、自分が詳しくない既存機能修正の場合は必要
1. 説明して、AIに質問させる
(CosenseのURL) これを作りたい。不明点・懸念事項があれば何でも私に質問してください。明確になってからplan modeに入りましょう
できるかぎり網羅的な説明をする
絶対plan mode使う。精度が違う
AIがかなり色々質問してくる
2. planから実装したらすぐbug修正
Codexに確認してもらい、単純なbugであれば修正してください。解決方法が複数ある場合は私に質問してください
不完全な実装を見なくて済む
最近はplan mode完了したらこれ実行しろとCLAUDE.mdに書いてるshokai.icon
良い感じになるまで1と2を繰り返す
コードレビューに向けて準備
3. pull requestを作る
pull requestを作ってください。概要欄は箇条書きで簡単に書いて
pull requestの概要欄は、人間が自分なりに書き直す
開発駆動仕様書にする
4. AIレビュー (1)
開発sessionのCladue Codeを使う
pull requestの概要欄とレビューコメントを書きました。間違いや説明不足な点があれば指摘してください
けっこう認識してない仕様が出てくる
typoも直る
5. 対話コンテキストをexportする
/conversation-context-export
6. AIレビュー (sanity-review)
新規sessionのClaude Codeを使う
(プルリクURL) を /sanity-review してください
レビュー報告書ができる
ここでもbugが見つかる事が多いので、修正するshokai.icon
レビューしてリリース
7 . 人間のレビュアーがpull requestの概要欄と、レビュー報告を読む
まだ不安がある時は
bugが無いかCodexと共に全力で確認してください
意外とまだ見つかるshokai.icon
8. リリースする
2, 4, 6でほぼ確実に毎回bugが見つかる
なんだかんだでAIが出すコードにはbugがある
疑問点・懸念事項が無くなったOpusがplan modeを経て出力したコードであっても
大変そうに見えるけど、並列してできる作業も多い
人間にもbugがある
AIとワーッと相談して出力したコードを理解できていない事がわりとある
特に私がshokai.icon
おわり：人やAIを信じれるようになった
開発メンバー.icon ↔ Claude Code.iconで何をやりとりしていたのかshokai.iconは知りたい → conversation-context-export
Claude Code.iconが出力するコードの品質を上げたい、bug無くしたい → codex-consultation
最終的に作られたコードをshokai.iconが正しく理解したい → sanity-review
開発メンバー.iconが正しく要件を理解しているか、shokai.iconは知りたい → sanity-review合格後の概要欄
shokai.iconがどういう観点でコードレビューしているか、開発メンバー.iconは知りたい → sanity-review
会場で写して大丈夫そうなpull requestを見繕っておく
ページタイトルのベクトル検索 #8262
client jsからのpages API v1の使用を完全に廃止した #8306
Infoboxの更新トリガーをサーバー側に移動 & 更新漏れしたページをフラグで検知してbatch処理で修復 #8463